System and method for reducing information volume in a blockchain distribution network

ABSTRACT

A server in a blockchain distribution network includes a processor and a transceiver operatively coupled to the processor. The transceiver is configured to receive a transaction from a peer node. The processor is configured to assign a transaction identifier to the transaction. The transceiver is configured to propagate the transaction identifier to one or more additional peer nodes and one or more additional servers in the blockchain distribution network. The transceiver is configured to receive bytes of a blockchain that represents a plurality of transactions. The blockchain includes the transaction identifier corresponding to the transaction. The transceiver is further configured to propagate the bytes of the blockchain to the one or more additional peer nodes and to the one or more additional servers in the blockchain distribution network.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims the priority benefit of U.S. ProvisionalPatent Application No. 62/557,330, filed on Sep. 12, 2017, the entiredisclosure of which is incorporated by reference herein.

BACKGROUND

A blockchain network refers to a distributed system that can be used tofacilitate transactions among parties. A typical blockchain networklacks centralized administration, and instead relies on mediation by aglobal peer-to-peer (p2p) network of participants. A blockchain includesan unalterable shared ledger that records a history of transactions.Because the blockchain ledger is unalterable and available to allinvolved parties of a given transaction, there is a reduced likelihoodof fraudulent transactions and erroneous ledgers. The use of ablockchain can also eliminate the need of a business to worry aboutdisparate ledgers, that would otherwise need to be reconciled.

SUMMARY

An illustrative server in a blockchain distribution network includes aprocessor and a transceiver operatively coupled to the processor. Thetransceiver is configured to receive bytes of a transaction from a firstpeer node. The transceiver is also configured to propagate the bytes ofthe transaction to one or more additional peer nodes and to one or moreadditional servers in the blockchain distribution network. Thetransceiver is also configured to receive bytes of a blockchain from asecond peer node. The blockchain includes information regarding aplurality of transactions, and the plurality of transactions includesthe transaction. The transceiver is further configured to propagate thebytes of the blockchain to the one or more additional peer nodes and tothe one or more additional servers in the blockchain distributionnetwork.

An illustrative method of propagating data in a blockchain distributionnetwork includes receiving, by a transceiver of a server, bytes of atransaction from a first peer node. The method also includespropagating, by the transceiver, the bytes of the transaction to one ormore additional peer nodes and to one or more additional servers in theblockchain distribution network. The method also includes receiving, bythe transceiver, bytes of a blockchain from a second peer node, wherethe blockchain includes information regarding a plurality oftransactions, and where the plurality of transactions includes thetransaction. The method further includes propagating, by thetransceiver, the bytes of the blockchain to the one or more additionalpeer nodes and to the one or more additional servers in the blockchaindistribution network.

An illustrative server in a blockchain distribution network includes aprocessor and a transceiver operatively coupled to the processor. Thetransceiver is configured to receive a transaction from a peer node. Theprocessor is configured to assign a transaction identifier to thetransaction. The transceiver is configured to propagate the transactionidentifier to one or more additional peer nodes and one or moreadditional servers in the blockchain distribution network. Thetransceiver is configured to receive bytes of a blockchain thatrepresents a plurality of transactions. The blockchain includes thetransaction identifier corresponding to the transaction. The transceiveris further configured to propagate the bytes of the blockchain to theone or more additional peer nodes and to the one or more additionalservers in the blockchain distribution network.

An illustrative method of propagating data in a blockchain distributionnetwork includes receiving, by a transceiver of a server in theblockchain distribution network, a transaction from a peer node. Themethod also includes assigning, by a processor operatively coupled tothe transceiver, a transaction identifier to the transaction. The methodalso includes propagating, by the transceiver, the transactionidentifier to one or more additional peer nodes and one or moreadditional servers in the blockchain distribution network. The methodalso includes receiving, by the transceiver, bytes of a blockchain thatrepresents a plurality of transactions, where the blockchain includesthe transaction identifier corresponding to the transaction. The methodfurther includes propagating, by the transceiver, the bytes of theblockchain to the one or more additional peer nodes and to the one ormore additional servers in the blockchain distribution network.

An illustrative server in a blockchain distribution network includes aprocessor and a transceiver operatively coupled to the processor. Thetransceiver is configured to receive bytes of an encrypted blockchainfrom a peer node in a peer-to-peer network, where the server is unableto identify a source node that generated the encrypted blockchain basedon the received bytes. The transceiver is also configured to propagatethe bytes of the encrypted blockchain to one or more additional peernodes and to one or more additional servers in the blockchaindistribution network.

An illustrative method of propagating information in a blockchaindistribution network includes receiving, by a transceiver of a server inthe blockchain distribution network, bytes of an encrypted blockchainfrom a peer node in a peer-to-peer network. The server is unable toidentify a source node that generated the encrypted blockchain based onthe received bytes. The method also includes propagating, by thetransceiver, the bytes of the encrypted blockchain to one or moreadditional peer nodes and to one or more additional servers in theblockchain distribution network.

An illustrative peer node in a blockchain distribution network includesa processor and a transceiver operatively coupled to the processor. Theprocessor is configured to generate a blockchain that includesinformation regarding a plurality of transactions. The processor is alsoconfigured to encrypt the blockchain. The transceiver is configured topropagate bytes of the encrypted blockchain to a second peer node thatis in communication with a server of the blockchain distributionnetwork.

An illustrative peer node in a blockchain distribution network includesa processor and a transceiver operatively coupled to the processor. Theprocessor is configured to generate an encrypted test block. Theencrypted test block is indistinguishable from an encrypted blockchainin the blockchain distribution network. The transceiver is configured totransmit the encrypted test block to a server for distributionthroughout the blockchain distribution network. The transceiver is alsoconfigured to receive a message from a second peer node in theblockchain distribution network, where the message indicates that thesecond peer node received the encrypted test block.

An illustrative method of peer-to-peer communication in a blockchaindistribution network includes generating, by a processor of a first peernode, an encrypted test block, where the encrypted test block isindistinguishable from an encrypted blockchain in the blockchaindistribution network. The method also includes transmitting, by atransceiver of the first peer device, the encrypted test block to aserver for distribution throughout the blockchain distribution network.The method further includes receiving, by the transceiver, a messagefrom a second peer node in the blockchain distribution network. Themessage indicates that the second peer node received the encrypted testblock.

An illustrative system for use in a blockchain distribution networkincludes a plurality of peer-to-peer nodes and a plurality of centralservers in communication with at least a portion of the plurality ofpeer-to-peer nodes. The plurality of peer-to-peer nodes includes a firstpeer node and a second peer node and the plurality of central serversincludes a first central server. The first peer node includes a firsttransceiver that is configured to transmit a blockchain to the secondpeer node. The second peer node includes a second transceiver that isconfigured to relay the blockchain to the first central server such thatthe first central server is unable to identify an origin of theblockchain.

An illustrative method of communicating in a blockchain distributionnetwork includes generating, by a processor of a first peer node, ablockchain, where the blockchain includes information regarding aplurality of transactions. The method also includes transmitting, by afirst transceiver of the first peer node, the blockchain to a secondpeer node. The method also includes relaying, by a second transceiver ofthe second peer node, the blockchain to a central server such that thefirst central server is unable to identify an origin of the blockchain.

An illustrative system for implementing payments in a blockchaindistribution network includes a first peer node that includes a firstprocessor configured to generate a blockchain that includes informationregarding a plurality of transactions. The plurality of transactionsincludes a plurality of fee transactions that each result in a paymentto the blockchain distribution network. For each of the plurality of feetransactions, the first processor is configured to generate paymentdetails to facilitate the payment to the blockchain distributionnetwork. The first processor is also configured to associate the paymentdetails with each of the plurality of fee transactions. The first peernode also includes a first transceiver operatively coupled to the firstprocessor and configured to transmit the blockchain for distributionthroughout the blockchain distribution network.

An illustrative method for implementing payments in a blockchaindistribution network includes generating, by a first processor of afirst peer node, a blockchain that includes information regarding aplurality of transactions. The plurality of transactions includes aplurality of fee transactions that each result in a payment to theblockchain distribution network. The method also includes generating, bythe first processor and for each of the plurality of fee transactions,payment details to facilitate the payment to the blockchain distributionnetwork. The method also includes associating, by the first processor,the payment details with each of the plurality of fee transactions. Themethod further includes transmitting, by a first transceiver of thefirst peer node that is operatively coupled to the first processor, theblockchain for distribution throughout the blockchain distributionnetwork.

An illustrative peer node in a blockchain distribution network includesa processor configured to generate a blockchain, where the blockchainincludes information regarding a plurality of transactions. Theprocessor is also configured to determine that the peer node is beingdiscriminated against with respect to blockchain transmissions by one ormore central servers of the blockchain distribution network. Theprocessor is further configured to determine, based at least in part onthe determination that the peer node is being discriminated against,that one or more servers in a sentinel network are to be used forblockchain transmissions instead of the one or more central servers. Thepeer node further comprises a transceiver operatively coupled to theprocessor and configured to transmit the blockchain through the sentinelnetwork.

An illustrative method of communicating in a blockchain distributionnetwork includes generating, by a processor of a peer node, ablockchain, where the blockchain includes information regarding aplurality of transactions. The method also includes determining, by theprocessor, that the peer node is being discriminated against withrespect to blockchain transmissions by one or more central servers ofthe blockchain distribution network. The method also includesdetermining, by the processor based at least in part on thedetermination that the peer node is being discriminated against, thatone or more servers in a sentinel network are to be used for blockchaintransmissions instead of the one or more central servers. The methodfurther comprises transmitting, by a transceiver operatively coupled tothe processor, the blockchain through the sentinel network.

Other principal features and advantages of the invention will becomeapparent to those skilled in the art upon review of the followingdrawings, the detailed description, and the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

Illustrative embodiments of the invention will hereafter be describedwith reference to the accompanying drawings, wherein like numeralsdenote like elements.

FIG. 1 is a block diagram depicting a server in a blockchaindistribution network in accordance with an illustrative embodiment.

FIG. 2 is a diagram that depicts interaction between system servers andpeer nodes in a blockchain distribution network in accordance with anillustrative embodiment.

FIG. 3 depicts block propagation by the system in accordance with anillustrative embodiment.

FIG. 4 depicts both encrypted and unencrypted block propagation in ablockchain distribution network in accordance with an illustrativeembodiment.

FIG. 5 depicts a block propagation process that includes peer-relayedencrypted block propagation in accordance with an illustrativeembodiment.

DETAILED DESCRIPTION

Blockchains are purely distributed systems that lack centralizedadministration and instead rely on mediation by a global peer-to-peer(p2p) network of participants. While such a design brings significantopportunities and disruptive potential in many areas, it is also thesource of a key problem in existing blockchain networks, which isscalability. As an example, a well-known blockchain referred to asBitcoin has a throughput 3-4 orders of magnitude smaller than that of acentralized counterpart, such as a major credit card carrier network.Described herein is a system that allows for blockchain scalability thatis attained via a centrally-managed network infrastructure. Thedescribed system also allows for complete decentralization of controlover transactions in that blockchain, attained via neutral and auditabledesign of the centrally managed network.

More specifically, the system described herein is a blockchaindistribution network (BDN) that disseminates transactions and blocks onbehalf of existing peer-to-peer blockchain nodes. It is shown that thepresent system increases a blockchain throughput by approximately onethousand times without affecting the functionality of the blockchain orthe balance of power among current system participants. This system isachieved in part by promoting neutral network design as the first-orderpriority for the system. The system described herein is the first tocombine a legacy p2p and a centrally managed BDN in which the p2pnetwork is used to audit the BDN and assess its neutrality. The systemis also protocol-agnostic and designed to support multiple blockchainssimultaneously.

The system described herein can be relied upon to scale blockchainsystems because the proposed system propagates encrypted data fromunknown origins, which prevents the system from discrimination andcensorship. The proposed system is the first blockchain distributionsystem to encrypt blocks prior to propagation in the network. Theproposed system is also the first to propagate keys within a blockchainnetwork. The keys are propagated in parallel by both system servers anddirectly between peers in the p2p network. Additionally, the keys arepropagated only after the blocks to which they correspond have beenpropagated in the network, which makes it too late for the network toreject them. The proposed system is also the first blockchain network toallow the sending of test blocks to see if they are propagated throughthe network. The test blocks allow the peer nodes to monitor the system,as discussed in more detail below.

The present system is also the first to allow relaying of encryptedblocks through peers to the centralized system, to hide both the contentand the origin of the blocks, thereby helping to prevent discrimination.The present system is also the first system to combine a p2p network anda centralized system such that the peers can audit the behavior of thecentralized system. The present system is also the first to use acentralized system to provide each transaction (which is ˜550 bytes)with a short ID, or transaction identifier, having a size of ˜2-3 bytes.By propagating a block that contains short IDs corresponding totransactions, as opposed to the transactions themselves, the actualamount of data in each block is considerably reduced. The blockrecipients are provided with information that enables them to translateback from short IDs to transactions. The proposed system is also thefirst to support multiple blockchain systems simultaneously. The presentsystem is further the first to suggest that each transaction willinclude a fee to the centralized system, and the first to use the peersto validate that the fees are actually paid to the centralized system.These unique features and attributes are described in more detail below.

The following is a discussion of existing blockchain distributionsystems and some of their limitations. Bitcoin is the first blockchainsystem and the first crypto-currency to gain considerable tractionglobally, with a market capitalization of over 50 billion U.S. dollars.A unique feature of Bitcoin is the lack of centralized administration.Rather, Bitcoin relies on third party mediation in the form of a globalp2p network of participants that validate and certify all transactions.Given the purely distributed and decentralized design of blockchains, itis believed that systems such as Bitcoin have a disrupting potential inmany other areas beyond crypto-currencies, including healthcare,government, manufacturing, retail, insurance, Internet of Things (IoT),sharing economy, etc.

A major problem for blockchains is scalability, which is fundamentallyhindered by the distributed system design and limitations of theunderlying p2p network model, as discussed in more detail below. Inparticular, a blockchain system throughput is measured in terms of thenumber of transactions per second (TPS) that the system can support.Currently, Bitcoin has reached its capacity with an average throughputof 2.67 TPS. For comparison to a centralized system, such as Visa, theaverage throughput is 2,000 TPS, with a daily peak at around 4,000 TPS,and a peak capacity at 56,000 TPS. Without scalability, crypto-currencysystems cannot become mainstream, and blockchains are unlikely torealize their disruptive potential in other areas such as thoseidentified above.

At its core, Bitcoin is a distributed system which allows its users tohold a balance and make transactions of Bitcoins, i.e., of currency, andmaintain a single distributed ledger of all transactions. Transactionsare not added to the ledger individually, rather, they are added inbatches, which are referred to as blocks. The result is a chain ofblocks which contains the entire history of all Bitcoin transactions,known as the blockchain.

To understand how Bitcoin transactions are created and the blockchainmaintained, assume user A is buying an item from another user B, andwishes to pay for it in Bitcoin. Each user controls a wallet, which is asimple private key and a public key pair. To pay user B, user A locallycreates a new transaction, which passes some amount of Bitcoins from herpublic key, also known as her address, to the address of user B. User Asigns the transaction using her private key. User A then propagates thetransaction to all other Bitcoin users. The Bitcoin network, whichcontains all Bitcoin users, is a p2p network. Every Bitcoin user, alsoreferred to as nodes, or peers, who receives the transaction validatesthat (i) all the transactions paying Bitcoins to user A's address, minusthe sums spent from her address, leave a balance which is greater thanor equal to the amount spent in the transaction, and (ii) that thetransaction contains a signature which requires knowledge of user A'sprivate key to be created. If these two conditions hold, the transactionis deemed valid, and users which receive it will propagate it to theirpeers. It is worth noting that a single entity may control any number ofwallets, and that each wallet can control any number of public keys.

In addition to regular Bitcoin users, some nodes in the Bitcoin networkattempt to aggregate the transactions they receive into new blocks,which will be added to the blockchain. It is only once a transaction isincluded in the blockchain that it is considered to have taken place,while transactions which still await to be included have not. Such nodesare called miners, and the process of attempting to create a new blockis known as mining. There are two monetary incentives for mining. First,each block contains a unique transaction, the coinbase transaction,which passes some amount of Bitcoins to the miner's address. The block'scoinbase transactions also provide the supply of Bitcoins, as it createsBitcoins. The amount of Bitcoin produced in each block decreasesexponentially over time, limiting the total supply to approximately 21million Bitcoins. Second, each Bitcoin transaction can carry a fee towhichever miner successfully includes it in a block, and miners areincentivized to include the transactions with the highest fees, sincethe number of transactions included in each block is limited.

To mine a new block, a miner hashes all the transactions to be includedin the block, using a double SHA-256 hashing function. In addition tothe transactions, the miner also hashes a timestamp, the result ofhashing the previous block, and an arbitrary binary value, known as anonce. For a new block to be created, i.e., for successful mining, theresult of the hashing must be very small. Thus, miners exhaustively trydifferent nonce values, in an attempt to find one which produces a smallenough value. The exact target value changes over time in an effort tomaintain an average of one block every 10 minutes, based on thetimestamps of the blocks.

Once a new block is found, it is propagated to the entire Bitcoinnetwork in a way similar to transactions (i.e., it is validated by eachnode prior to its propagation). It is safe for the successful miner topropagate its block, including the nonce, since the nonce only yields asmall enough value for the newly-mined block, without any change done toit. A dishonest user cannot utilize the nonce to create an alternativeblock, e.g., with a coinbase transaction which passes Bitcoins to thewallet of the dishonest node. Such a change will cause the block'shashing to yield a different value, and the nonce has the sameprobability as any other arbitrary value to yield a value smaller thanthe target.

A critical aspect of blockchain security is that the hashing of eachblock also includes the value yielded from hashing the block precedingit. The immediate result of this inclusion, is that any attackerattempting to alter the history of transactions, i.e., the inclusion,exclusion, or alteration of a transaction in some previous block, willchange the value its hashing yields. This in turn will affect thehashing value of all consecutive blocks, and almost certainly invalidateeach and every one of them. For such an alteration to succeed, theattacker would have to sequentially find a new nonce for every block.Moreover, the attacker would have to do so at a higher rate than therate at which all other miners extend the original blockchain. Thus, forsuch an attack to succeed, the attacker must control the majority ofhashing power in the Bitcoin system. It has been shown that entitiescontrolling less than 50% of the hashing power can gain unfairadvantage, and thus can eventually eliminate smaller miners and gainmajority of hashing power. However, the above-described securityprimitive based on block hashing differentiates Bitcoin and blockchainsystems from previous decentralized systems.

A unique feature of Bitcoin, and of blockchain systems in general, istheir inherent ability to overcome inconsistent views of the transactionhistory in a distributed manner, by defining the blockchain whichrequires the most computation to produce as the ‘true’ blockchain. Todemonstrate this ability, consider two miners which happen tosuccessfully mine a new block at approximately the same time. The twoblocks differ from each other as they will contain different coinbasetransactions, use different nonces, and it is very likely thetransactions included in each of them are not identical. Once the twoblocks are mined, they are propagated in parallel to the entire Bitcoinnetwork, resulting in some portion of the network considering onehistory of transactions to take place, while others consider a slightlydifferent version of transaction history to take place. Such asituation, where two or more equally valid blockchain versions exist iscalled a fork. While a fork is unresolved, there exists some ambiguityregarding which transactions have taken place.

Forks are resolved once a new block is mined, as it causes one prong ofthe fork to become longer than others, which in turn incentivizes minersto abandon the shorter prongs and attempt to mine over the longestblockchain, as any rewards gained on shorter prongs are likely to beorphaned (i.e., discarded). Thus, the Bitcoin system converges to thelongest blockchain due to the selfish interests of the miners. It ispossible yet rare for blocks to be mined for two prongs of a fork atapproximately the same time, which keeps the fork unresolved, until onebecomes longer than the other.

Due to the possibility of forks, it is possible for a transaction to beincluded in a block, yet not to be included in the blockchain if theblock is orphaned. The probability for a block to be orphanedexponentially decreases as more blocks are mined on top of it, in directrelation to the probability for two blocks to be mined on two prongs ofa fork at approximately the same time. Thus, transactions are consideredmore secure as additional blocks are mined on top of the blockscontaining them.

The Bitcoin model, as outlined above, does not depend on any centralizedentity to track balances or to execute transactions, nor can any singleentity undo transactions, confiscate Bitcoins, or alter the blockchainin any way without control over a majority of the hashing power. Toenforce new transactions on behalf of users, such an entity will berequired to break the SHA-256 hashing. Bitcoin is thus considered atrustless system since users do not depend on any central entity toperform any action on its behalf, or to provide it any information, suchas wallet balances, upon which it relies.

In Bitcoin, as in other cryptocurrencies and blockchain systems, systemthroughput is measured by the number of transactions per second (TPS) itsupports. Since the Bitcoin network produces one 1 MB block once every10 minutes, on average, and average transaction size is 544 bytes, theBitcoin system handles an average of 1764 transactions per 10 minutes,or 2.94 TPS. In comparison, as discussed above, Visa performs 2000 TPSon average, with an average daily peak of 4000 TPS, and can support upto 56,000 TPS. Moreover, cryptocurrencies aim to enable low feetransactions of very small sums (mircropayments), which are expected toinvolve a considerably higher throughput than Visa, MasterCard, andPaypal combined.

The Bitcoin system throughput directly depends on 2 parameters: theblock size (B), i.e., the number of bytes which can contain transactionsin each block, and the inter-block time interval (t_(B)), which is theaverage time required for the system to mine a new block. As notedabove, in Bitcoin B=1 MB and t_(B)=600 seconds, which allows 2.94 TPS.To improve Bitcoin's throughput, it is possible to increase the B toinclude more transactions, and to reduce t_(B), so that blocks are minedat a higher rate. However, these parameters also critically affect thesystem decentralization, usability, and security, as detailed below.

Traditional blockchains, such as Bitcoin, are not easily scalable. Theinventors have determined that block propagation time is the limitingfactor of the throughput in such a blockchain system. The inventors havealso determined that increasing system throughput negatively affectsblock propagation time, which in turn reduces the security and theusability of blockchain systems.

If newly-mined blocks were instantaneously propagated to the entireBitcoin network, it would be possible for it to process thousands ofTPS, using larger blocks B mined at shorter time intervals t_(B), as ithas been shown that a modern processor can support thousands of TPS,while disk I/O can support hundreds of thousands of TPS. In contrast,Bitcoin's networking aspects in general are much more constrained. Whilep2p protocols have been proven capable of quickly propagating data amongpeers (e.g., Bittorrent), Bitcoin and other blockchain systems differfrom classical p2p networks by requiring the continuous delivery of allblocks to all peers.

Unlike traditional p2p systems, Distributed Denial of Service (DDoS)attacks are prevalent in blockchain systems, and are used to gainadvantages in mining, voting, and other business-related andprotocol-related activities. To prevent malicious nodes from floodingthe network with invalid blocks, nodes use a store-and-forwardpropagation model, where each node must first download and validateevery block, prior to propagating it to its peers. This model allowsnodes to identify any node which propagates invalid blocks as malicious,and limits the effect of such attacks to the nodes which are directlyattacked.

Block propagation time directly affects the security and usability ofthe blockchain, since it defines the time window in which forks occur.As this time window increases in size, the probability of a forkincreases by a similar factor. Considering Bitcoin mining, which followsthe exponential distribution with a mean of 600 seconds (t_(B)=600), andthe block propagation to 90% of the network (t₉₀ ^(th)) to be the blockpropagation time, the probability for a fork to occur while a new blockis mined approximates:

$\begin{matrix}{{P\left( {\left. {fork} \middle| t_{B} \right. = 600} \right)} = {1 - e^{\frac{- t_{90^{th}}}{600}}}} & {{Equation}\mspace{14mu} 1}\end{matrix}$

Thus, the probabilities of a fork to occur where, e.g., t₉₀ ^(th)=0.9,9, and 90 seconds, are 0.1499%, 1.489%, and 13.93%, respectively.

The increase in fork probability has an exponential effect on theprobability for a fork to last several blocks, requiring more blocks tobe mined before a transaction is considered safe. For example, theprobability for a fork to last 6 blocks when t₉₀ ^(th)=9 seconds isalmost 1,000,000 times larger than when t₉₀ ^(th)=0.9 seconds. Moreover,to match the low probability of a transaction to be orphaned after 6confirmations where t₉₀ ^(th)=0.9 seconds, i.e., after 5 blocks had beenmined after it was included in a block, a transaction in which t₉₀^(th)=9 seconds must have 10 confirmations.

Block propagation time also directly affects the ability of nodes toparticipate in the Bitcoin network, as nodes must be capable ofreceiving blocks at a higher rate than they are produced. Failing toachieve this, nodes cannot track the balances stored in the blockchain,and thus they cannot determine the validity of transactions and blocks,and are in effect excluded from the Bitcoin network. To allow 90% ofnodes to remain in the network, the block to propagation time for 90% ofthe network must be smaller than the inter-block time interval t₉₀^(th)<t_(B).

Another effect of block propagation time is on the profitability ofminers. Once a new block is mined, miners which have not yet receivedthe new block become considerably less profitable, as any block theymine will cause a fork and are likely to be orphaned. The probabilityfor a block to be orphaned depends on the rate at which it is propagatedto the network. Thus, it is in the best interest of miners to receiveblocks as soon as possible, and to have their own blocks propagate asfast as possible. Large mining operations, known as mining farms, investlarge sums in mining hardware and infrastructure, and their investmentin networking infrastructure is proportionally small, leveraging theeconomies of scale. Small mining operations invest proportionally largersums to achieve the same networking performance, and are thus lessprofitable. Since the security of Bitcoin and other blockchain systemsdepend on the decentralization of mining, such a centralization forcehas an adverse effect on their security.

In the year 2017, the Bitcoin network included approximately 9,000 nodes(N=9,000), the majority of which are connected to 8-12 of their peers,with a median latency between peers of approximately 110 milliseconds.At the 50^(th) percentile, node upload rate is 56 Mbps (bw₅₀ ^(th)=56Mbps), while the 10^(th) and 1^(st) percentiles have a rate of 3.96 Mbpsand 438 Kbps, respectively. Thus, the upload rate at the 50^(th),10^(th), and 1^(st) percentile supports 13,000,943 and 100 TPS,respectively. It is noted that global bandwidth measurements show thatdownload rates exceed upload rates by a factor of 1.85-5.81, with theexception of low constraint regions where the average bandwidth exceeds100 Mbps.

The bandwidth of individual Bitcoin nodes supports increasing the systemthroughput by orders of magnitude, and the latency among peers is not soabnormally high as to pose a barrier. However, while individual nodescan easily support higher TPS, it is the distributed propagation whichBitcoin and other blockchain systems employ that significantly limitsthe system throughput.

As discussed above, in order for Bitcoin to function as a decentralizedsystem, it must allow nodes to receive blocks at a higher rate than theblocks are produced. Indeed, if blocks are produced at a higher ratethan a node is capable of receiving them, then the node cannot keeptrack of balances stored in the blockchain, cannot determine whether ornot transactions and blocks are valid, and is in effect excluded fromthe Bitcoin Network. The block propagation time to the majority of thenetwork (t₅₀ ^(th)) does not depend solely on a receiving nodebandwidth. Rather, it depends on network topology, the bandwidth of allnodes, and the manner in which blocks propagate.

The time that it takes for a block to propagate through the system, andhow it is affected by the block size (B), can be roughly approximatedbased on the number of nodes (N) and their median bandwidth (bw₅₀^(th)). For a median Bitcoin node, the time to transmit a single 1 MBblock to a single peer (t_(hop)) is roughly:

$\begin{matrix}{t_{hop} = {\frac{B}{{bw}_{50^{th}}} = {\frac{1\mspace{14mu} {MB}}{56\mspace{14mu} {Mbps}} = {0.143\mspace{14mu} {seconds}}}}} & {{Equation}\mspace{14mu} 2}\end{matrix}$

Assuming 8 peers, the average Bitcoin node will use approximately8t_(hop) to propagate a block to its peers, regardless of whether suchpropagation is done sequentially or in parallel. However, sequentialpropagation allows the first peer of a node to propagate the receivedblock after t_(hop) has passed, while parallel propagation will onlyallow peers to propagate the block after 8t_(hop). Thus, to hasten blockpropagation when bandwidth is limited, nodes would ideally propagateblocks to their peers sequentially, rather than in parallel.

Using sequential propagation, a newly-mined block is known only to asingle node, i.e., its miner, at time t=0, to two nodes, the miner andits first peer, at time t=t_(hop), to 4 nodes at time t=2t_(hop), and toa majority of the network at time:

t ₅₀ ^(th)=[log 2(N)]t _(hop)=13t _(hop)=1.86 seconds  Equation 3:

While this approximation does not account for network congestion,download bandwidth, message exchange overhead, latency, packet loss, thearbitrary topology of the nodes, or bandwidth consumed for transactionspropagation, it does provide insights regarding block propagation time(t₅₀ ^(th)).

It is noted that while the network size (N) effect over the blockpropagation time (t₅₀ ^(th)) is logarithmic, the effect of block size(B) is linear. For example, increasing the system TPS by a factor of 10by increasing the block size to B=10 MB would increase the time requiredfor the median node to transmit a block to a single peer by the samefactor, to

$t_{hop} = {\frac{10\mspace{14mu} {MB}}{56\mspace{14mu} {Mbps}} = {1.43\mspace{14mu} {{seconds}.}}}$

This, in turn, would increase the block propagation time to the majorityof the network by the same factor to t₅₀ ^(th)=13t_(hop)=18.6 seconds.The linear effect of block size (B) on block propagation time (t₅₀^(th)) has also been empirically found in various studies, when blocksize (B) exceeds 20 KB.

The positive and negative effects of increasing block size (B), i.e.,increased system throughput, reduced blockchain security, and nodeexclusion, are symmetric to the effects of reducing the average timerequired to mine a new block (t_(B)) by the same factor. For example,doubling the block size (B) would increase the system throughout by afactor of 2, and the same is achieved by halving the inter-block timeinterval (t_(B)). Similarly, doubling the block size will approximatelydouble the block propagation time (t₉₀ ^(th)), which in turn will doublethe probability of forks as follows:

$\begin{matrix}{{P({fork})} = {1 - e^{\frac{- t_{90^{th}}}{t_{B}}}}} & {{Equation}\mspace{14mu} 4}\end{matrix}$

It is noted that halving the inter-block time interval (t_(B)) will havethe same effect. Also, doubling to include 90% of the nodes in thenetwork, the block propagation time at the 90^(th) percentile must besmaller than the inter-block time interval (t₉₀ ^(th)<t_(B)). Doublingthe block size (B) would increase block propagation time (t₉₀ ^(th)) bya similar factor, which will have the same effect as halving t_(B).

While the system described herein is the first BDN that comprehensivelyaddresses the blockchain scaling problem (i.e., via transactionpropagation and indexing, block propagation, neutral and auditable BDNdesign, etc.), advanced block propagation for a subset of nodes (miners)has been deployed in the context of the Bitcoin network. In particular,in order to minimize the negative effects of long block propagationtimes, as well as to put smaller miners on equal terms with largermining farms, centralized Bitcoin relay networks were deployed.

The first relay network to be deployed, referred to as the Bitcoin FastRelay Network (BFRN), relays blocks using multiple gateways around theglobe to reduce block propagation time for miners. The BFRN focuses onutilizing low-latency connections to reduce the block propagation timewhich is the result of ineffective routing and geographic distances. TheBFRN was later replaced by the Fast Internet Bitcoin Relay Engine(FIBRE), which uses a similar architecture while utilizing fiber-opticwires and forward error correction (FEC) to further reduce latency andpacket error rate. The goal of FIBRE was to minimize the number of roundtrip times (RTTs) required to propagate a block.

The Falcon network was another attempt to reduce latency. The Falconnetwork follows similar principals to FIBRE, yet it also aims to reduceblock propagation time further by avoiding the need to receive an entireblock prior to propagating it. Instead, Falcon utilizes a cut-throughrouting scheme, where gateways to the relay network relay the firstbytes of an inbound block as soon as they arrive, rather than wait forthe entire block to arrive.

While both FIBRE and Falcon provide an effective service to the Bitcoinnetwork, the Bitcoin system cannot rely on them to achieve higherthroughput without subjecting itself to their control and forfeiting theunique decentralized nature of the Bitcoin network. The administrator ofa relay network can reject blocks containing specific addresses, and canthus censor and limit the usage of the blockchain. The administrator ofthe relay network can also avoid relaying blocks from or to specificminers, and serve only a subset of miners, providing them with influencewhich exceeds their proportional computational power, thus breaking thesecurity model of the blockchain. The relay network administratorbehavior could be malicious, selfish, or obliged by national andinternational laws.

The deployment of BFRN, FIBRE, and Falcon has had a significant effecton block propagation time, reducing it from 1-2 minutes to severalseconds. Unfortunately, this improvement prevents any real-world blockpropagation measurement which does not use a relay network. Theinventors therefore focused on block propagation measurements takenprior to the deployment of such relay networks, in conjunction withsimulations which are based on recent networking measurements.

Another proposed scaling solution for blockchain networks, known asside-channels or off-chain transactions, suggests that parties will use‘smart contracts’ which set aside some amount of the parties' currency.The set aside currency is then used by the parties to transact amongthemselves numerous times, until such time that the smart contractexpires, and the result of all the transactions done are returned to theinvolved parties. Another approach, known as ‘sharding,’ splits theblockchain into several smaller ‘shards,’ which are maintained andinterleaved in a fashion that aims to keep the original securityproperties of the blockchain. Other approaches, such as Bitcoin-NG andScepter, replace blocks by a stream of transactions, or forgo themaltogether, while still other systems aim for nodes to place trust inspecific nodes, and to assure their honest behavior through the abilityto replace them.

While the above approaches may have some potential, their robustness,security, usability, and adaption remains to be proven. Moreimportantly, side-channels still require the use of multiple on-chaintransactions to open and close smart contracts, while sharding requiresscale per shard, making them compatible and in need of an on-chainscalability solution. The propagation needs of Scepter and Bitcoin-NGremain to be seen, if they are ultimately deployed.

System Design

Given the above-described deficiencies in existing blockchain networks,one goal of the present system is to enable crypto-currencies andblockchain systems to scale to thousands of on-chain transactions persecond. Moreover, the present system aims to provide scalability tonumerous crypto-currencies and blockchain systems simultaneously,utilizing a centrally managed infrastructure to support distributedblockchain systems in a provably neutral fashion.

The system described herein represents a fundamental change inapproaching the blockchain scaling problem. Instead of strictly relyingon a purely distributed system design, the system embraces a blockchaindistribution network (BDN) to enable blockchain scaling withoutcompromising the decentralization of control over transactions in theblockchain. The key challenges are to design such a BDN to be neutraland auditable by a global peer network, while retaining existingblockchain functionality, properties, and balance of power among currentsystem participants.

To achieve scalability, the present system disseminates bothtransactions from peer network nodes to the rest of the peer network,and blocks that aggregate transactions from miners to the rest of thepeer network. Unique to the design of the present system is its abilityto effectively index all the transactions in the system with identifiers(IDs) that are approximately two orders of magnitude shorter than theoriginal transactions. This in turn reduces the effective block size,and increases system throughput, by the same two orders of magnitude. Inaddition, the swift, coordinated, cut-through block propagation via thesystem servers adds one additional order of magnitude in throughputrelative to the state-of-the art p2p blockchain systems, leading to anapproximate 1000 fold overall increase in system throughput (i.e., TPS).

Neutrality refers to the propagation of blocks without knowledge of thetransactions they contain, their number, their sums, the walletsinvolved, the addresses involved, the miner to produce each block, orthe IP address of a miner that mined the block. In addition, miners arefree to include arbitrary transactions in a block, even those that werenot originally distributed and indexed by the system. Furthermore, thesystem, or its administrator, cannot infer the above characteristicseven when colluding with other nodes of the peer network, or byanalyzing the timing and size of blocks. The system is unable to favorspecific nodes by providing them blocks ahead of others, and cannotprevent any node from joining the system and utilizing it. The systemcan either fairly propagate all blocks, or none of them.

To achieve neutrality and enable its auditing, the present systemsupports encrypted blocks, which prevents the system from stopping theblock propagation based on its content or any other feature. Anencryption key for the block is only revealed after the block has beenpropagated through the network. To ensure that the system is notdiscriminating against individual nodes, clients do not propagate blocksdirectly to the system servers, but instead relays them via peers in thepeer network, obscuring the origin of the block from the system BDNservers. To prevent the system BDN servers from blocking or stallingblocks arriving from a particular set of nodes, clients are able toaudit the system by testing its service and communicating the results toother peers. Clients are therefore allowed to send test blocks directlyto the system. Additionally, a sentinel network is available and readyto assume the role of the system BDN servers in case the system fails tofaithfully serve the peer network nodes, whether deliberately, or as aresult of a large-scale system failure.

The system as a whole is protocol-agnostic, and capable of providing itsscaling services to numerous crypto-currencies and blockchainssimultaneously. In addition, the system is an economically sustainablesystem. Economic sustainability is accomplished by enabling existingendpoints to directly assign a fraction of the fees intended for minersto the system blockchain distribution network (BDN) servers. The overalleffect, enabled by system scaling, is beneficial to all involvedparties. For example, miner earnings can increase by 10× and client feescan be reduced by 100×, making the system BDN economically viable.

To summarize, the present system is the first BDN system that utilizes acentrally managed infrastructure to scale blockchains without affectingthe decentralization of control over transactions in a blockchain. Thesystem increases a blockchain throughput by ˜1000× compared totraditional networks via efficient content dissemination and byproviding a mapping service between transactions and short IDs, thusreducing the traffic volume. The proposed BDN system is the firstnetworking system to scale blockchain systems as a whole, rather thanjust increasing fairness or reducing latency for individual nodes.Network neutrality is defined for the first time in the context ofblockchains, and as discussed in detail below, the inventors havedesigned, implemented, and evaluated the first such neutral BDN, anddemonstrated its fairness and anti-discriminatory properties.

The system is also the first to combine a p2p and centrally managed BDNnetwork where the p2p network is used to audit the centrally managednetwork and assess its neutrality. The proposed system is the firstsystem to include direct on-chain payments for BDN services, a featurethat is only incrementally deployable in existing crypto-currencies,thus making BDN services a first-class citizen in the blockchainecosystem for the first time. The proposed system is also the first toprovide a BDN network that can support multiple blockchains, agnostic totheir implementation and protocols. The proposed system is also thefirst to combine a p2p network and a centrally managed BDN network toprohibit the BDN network from censoring content. The system is furtherthe first to introduce a sentinel network to protect against large-scalediscrimination and collusion attempts.

The trust model of the present system is based on two observations.First, it has been observed that trustless p2p blockchains such asBitcoin cannot scale to thousands of on-chain transactions per second,due to their long block propagation time, as discussed above. Second, ithas been observed that better scalability is achievable by placing trustin a small subset of participants, and passing them the control over thetransactions included in the blockchains, e.g., Ripple, EOS, BitShares,Steem, etc. However, such centralization defeats the single most notableaspect of distributed blockchains, which is the distribution anddecentralization of control over transactions. Providing control overtransactions in a blockchain to a limited number of participants allowsthose participants to collude, censor, and discriminate between users,nodes, and miners. Provision of control to such a limited number ofparticipants can also easily make those participants accountable for thetransactions they include by law enforcement.

Rather than placing trust in a subset of nodes to enable scalability,the present system utilizes a trust model that reverses the direction oftrust, and enables scalability using a subset of nodes which must placetrust in the entire network. The system utilizes a BDN system to enablescaling, yet nodes need not place any trust in the BDN. Instead, the BDNsystem blindly serves the nodes, without knowledge of the blocks itpropagates, their origin, or their validity. Moreover, the behavior ofthe BDN is constantly audited by the nodes it serves, and it isincapable of discriminating against individual nodes, blocks, ortransactions. While such design places the BDN system at a disadvantagecompared to the nodes utilizing it, its robustness allows it towithstand dishonest and malicious behaviors, as discussed in more detailbelow.

In an illustrative embodiment, the proposed BDN system includes aplurality of system servers, a plurality of peer nodes in a peernetwork, and a sentinel network of nodes. FIG. 1 is a block diagramdepicting a system server 100 in a blockchain distribution network inaccordance with an illustrative embodiment. As indicated in FIG. 1, thesystem server 100 includes a processor 105, a memory 110, a transceiver115, and an interface 120. In alternative embodiments, fewer,additional, and/or different components may be included in the systemserver 100. The memory 110 can be any type of computer-readable mediumthat is configured to store computer-readable instructions to implementany of the operations, programs, and algorithms described herein. Theprocessor 105 is configured to execute the computer-readableinstructions stored in the memory 110. The processor 105 is alsoconfigured to control the transceiver 115 such that blocks, packets, andother information can be received and transmitted by the system server100. The transceiver 115, which is used to receive/transmit information,can be any type of transceiver. The transceiver 115 can be in the formof a single component that both sends and receives, or alternatively thetransceiver 115 can be in the form of a distinct receiver and a distincttransmitter. The interface 120 can be any type of input/output (I/O)component such as a display, keyboard, mouse, data port, etc. thatallows an individual to interact with the server 100.

FIG. 2 is a diagram that depicts interaction between system servers andpeer nodes in a blockchain distribution network in accordance with anillustrative embodiment. The system servers form a high capacity, lowlatency, global BDN network that is optimized to quickly propagatetransactions and blocks for multiple blockchain systems. The peer nodesof FIG. 2 (i.e., p_(source), p₁, p₂, p₃) are p2p network nodes whichutilize the system servers to propagate transactions and blocks, whilecarefully auditing the behavior of the overall BDN. The present systemcan include a plurality of p2p networks, in which each peer networkincludes all of the nodes using a specific protocol. For example, all ofthe Bitcoin nodes utilizing the system servers form a first peernetwork, while all of the Ethereum nodes utilizing the system serverscan form a second peer network. In the embodiment of FIG. 2, each nodein the peer network includes a peer process and a blockchainapplication. A given peer node runs its peer process as an intermediarybetween its blockchain application and the system servers. Although thediagram of FIG. 2 depicts 4 system servers and 4 peer nodes forillustration, it is to be understood that a typical BDN will includesignificantly more system servers and peer nodes.

In addition to the aforementioned system servers and the peernetwork(s), the system can also include a backup network, which isreferred to as a sentinel network. The sentinel network (not shown inFIG. 2) is a distributedly-managed global network of servers, ready toassume the role of the system servers should the need arise. While thesystem servers remain operational, the sentinel network does notpropagate any traffic.

The system servers propagate blocks on behalf of the nodes in the peernetwork(s). However, contrary to relay networks, the system serverspropagate blocks without knowledge of the transactions they contain,their number, their sums, the wallets or addresses involved, the minerthat produced each block, or the IP address from which a block entersthe BDN. Furthermore, the system servers, or their administrator, cannotinfer the above characteristics even when colluding with other nodes ofthe peer network, or by analyzing block timing and size. The systemservers cannot favor specific nodes by providing them blocks ahead ofothers, and cannot prevent any node from joining the system andutilizing it. The system servers can either fairly propagate all blocks,or none of them, and are incapable of discrimination.

The BDN as a whole is protocol-agnostic, providing its scaling servicesto numerous cryptocurrencies and blockchains simultaneously. The systemservers operate at the transport layer of the open systemsinterconnection (OSI) model, interacting with both the application layerand the networking layer, and provide service to whichever blockchainprotocol is running at the application layer. However, some of thefunctionalities of the system servers fall under the application layer,a design decision which allows compatibility with both new and existingcryptocurrencies. More specifically, functionalities which fall underthe networking layer include receiving blocks from the blockchainapplication, sending blocks to other peers, block encryption, sendingencryption keys, and receiving unencrypted blocks from peers.Functionalities which fall under the application layer include the useof the transmission control protocol (TCP) and user datagram protocol(UDP) to send data, the discovery of peers, connecting the blockchainapplication to the peer process, and sending test blocks to ensure thatthe BDN network is not discriminating.

In order to reduce transaction size by orders of magnitude, and thus toreduce block size and propagation time, each transaction is matched witha short ID, which is consistent across all parts of the system. Usingthese short IDs, blocks are propagated containing only the transactionIDs, rather than the transactions themselves, to minimize blocks size.After an encrypted block is received by a node, and once the nodereceives the encryption key needed to decrypt it, the node is then ableto translate the short IDs back to transactions, prior to testing thevalidity of the received block.

Unlike distributed systems, where such techniques open the door toattack vectors based on ID collision, the present system, being acentralized system, can use IDs safely and in a more efficient manner byusing shorter IDs. This allows the system to increase its throughput byorders of magnitude, as for any given block size, more transactions canbe included.

For a transaction to be matched with an ID, the transaction is sent tothe system servers by any of the nodes they serve, which may or may notbe the transaction creator. The system servers then disseminate thetransaction alongside its ID to all the nodes it serves, as well as atime-to-live (TTL) field, which specifies the longevity of the mappingbetween the transaction and the ID. Such a mapping between transactionsand corresponding IDs is then cached at peer nodes. This process allowspeer nodes to effectively shorten the size of a block (by using IDsinstead of raw transactions). At the same time, the mapping helpsreceiving peer nodes reassemble the raw blocks by converting from IDs toraw transactions.

To enable blockchain scalability, the system servers propagate blocksquickly and efficiently to all peer network nodes, as shown in FIG. 3.Once a newly mined block is found by a node (p_(source)) of the peernetwork, whether mined by p_(source) or propagated to it by its peers,the block will be disseminated in a process that can include 5operations. In alternative embodiments, fewer or additional operationsmay be performed. FIG. 3 depicts block propagation by the system inaccordance with an illustrative embodiment.

As illustrated in FIG. 3, at a first operation (1), a blockchainapplication at p_(source) passes a raw block to a peer processassociated with p_(source). The system is compatible with all blockchainapplications, and the peer process is used as an intermediary betweenthe blockchain application and the system servers. The peer process caninclude hardware and/or software as known in the art of p2p networking.At a second operation (2), the peer process shortens the block viatransaction IDs and transmits the block to one of the system servers(i.e., Server₂). At a third operation (3), a system server that receivedthe block distributes the block to all other system BDN servers as theblock is received. More specifically, as the first bytes of the blockare received at the system server, they are immediately propagated toall other system servers without waiting for the entire block to bereceived. At a fourth operation (4), system servers propagate the blockto all peers, and this is again done as the block is received. Morespecifically, as the first bytes of the block are received at all of thesystem servers, they are immediately propagated to the peer processesrunning at all of the peer network nodes (p₁, p₂, p₃, and so on),without waiting for the entire block to be received. At a fifthoperation (5), peer processes validate block structure, reassemble theraw block, and pass the assembled block to a blockchain application. Allof the peer network nodes (p₁, p₂, p₃) are expected to receive the blockin its entirety approximately 2 RTTs after p_(source) completes theblock transmission to the initial system server.

To prevent the system servers from rejecting blocks based on thetransactions they contain, the block dissemination process discussedabove can be extended to include encryption. FIG. 4 depicts bothencrypted and unencrypted block propagation in a BDN in accordance withan illustrative embodiment. In FIG. 4, encrypted block propagation isdepicted by a dotted arrow line that extends over a solid arrow linewhich represents unencrypted block propagation. With reference toencrypted block propagation, at a first operation (1), a blockchainapplication of p_(source) passes a raw block to a peer process ofp_(source), which shortens and encrypts the block, and propagates theencrypted block to all of the peer network nodes (p₁, p₂, p₃) via thesystem servers. At a second operation (2), each of the nodes (p₁, p₂,p₃) notifies its peers of the received encrypted block using theencrypted block's hash value. At a third operation (3), once the peernode p_(source) receives notifications from its peers (p₁ and p₂) thatthe encrypted block has been propagated, p_(source) propagates theencryption key required to decrypt the block using p2p propagation andthe system servers. At a fourth operation (4), each peer process thatreceives the propagated encryption key decrypts the encrypted block,validates the structure of the block, reassembles the raw block, andpasses the raw block to the blockchain application.

To prevent the system BDN from rejecting blocks based on their origin,i.e., based on the source node attempting to propagate a newly minedblock, blocks are not sent directly to system servers. Rather, blocksare relayed to system servers via a peer, obscuring their origins. FIG.5 depicts a block propagation process that includes peer-relayedencrypted block propagation in accordance with an illustrativeembodiment. In FIG. 5, peer relayed encrypted block propagation isindicated by a dotted arrow line that extends over an encrypted blockpropagation that is represented by a solid arrow line. In a firstoperation (1), the blockchain application of a source node p_(source)passes a block to its peer process, which shortens and encrypts theblock. In a second operation (2), the peer process of p_(source) relaysthe encrypted block, along with the unencrypted block's header to apeer, which in this example is p₁. The recipient peer (p₁) validates theheader and then relays the encrypted block to a system server. The blockdissemination then follows the encrypted block propagation discussedabove with reference to FIG. 4.

In an illustrative embodiment, the above-referenced block header can bean 80 byte block header. Alternatively, a different length header can beused. The block header includes a version field, a previous block headerhash field, a Merkle root hash field, a time field, an nBits field, anda nonce (i.e., an arbitrary binary value) field. In alternativeembodiments, fewer, additional, and/or different fields may be includedin the block header. For a block to be valid, the hashing of thesefields has to be very small, i.e., smaller than the nBits field, whichis a very small binary value. Thus, in order to create a new block,miners can try different arbitrary values in the nonce field until oneof them works. A result is that it takes a lot of work to create a validheader, which makes it highly unlikely and expensive for an individualto create a valid header for an invalid block. Analysis of the blockheader is therefore almost certainly enough to test whether the block isvalid, and peer nodes can determine whether to further relay the blockbased on whether the block is found to be valid.

The BDN also provides a provably neutral block dissemination service byallowing its clients (i.e., the peer network nodes) to continuouslymonitor its behavior using test-blocks, and through its ability topropagate unvalidated encrypted data. This puts the BDN at adisadvantage in comparison to its clients, and opens the door toresource-wasting malicious behavior, which the BDN is robust enough towithstand.

The BDN robustness and service incurs costs mainly in the form of thedelivery of large traffic volumes to a large number of nodes. Forexample, one can assume a network of 10,000 full nodes, which is similarin size to today's Bitcoin network. Each of these nodes in the networkmay create, for example, four 1 MB test-blocks per day, and the BDNwould be delivering 100 TB per day, or 9.26 Gbps. At the same time,assuming transactions are created at a rate of 3,000 TPS, their deliverywould utilize an additional 132 Gbps. It is noted that the bandwidthutilized to support test-blocks increases exponentially as the number offull nodes increases, while the bandwidth required to support higher TPSdoes not. The cost of supporting a reliable, low-latency, globalinfrastructure which immediately delivers these large traffic volumes isnon-negligible.

To assure sustainability of the BDN, transactions of blockchain systemswhich utilize the BDN may be required to pay an additional fee to theBDN. This BDN fee has several key properties. The BDN fee is minusculein comparison to the fees reduced for users, and to the sum of feeincreases for miners, due to the scalability it allows. For eachtransaction, the BDN fee is 10% of the miner fee, and the BDN system'spublic address is added as an additional payee. Such a fee is very smallin comparison to the several orders of magnitude increase to the systemthroughput, which translates to an order of magnitude fees reduction forusers and an order of magnitude increase in fees collected by miners,while keeping the BDN profitable and sustainable. Additionally, definingthe BDN fee as a percentage of the miner fee assures that the incentivemechanism to prioritize transactions based on their fees remainsunaffected.

While most transactions in the BDN result in a fee paid to the BDNsystem, in one embodiment ˜20% of the size of each block can bededicated for transactions which do not include such a fee. Inalternative embodiments, a different percentage may be used such as 5%,10%, 15%, 25%, 30%, etc. The BDN differentiates between three types oftransactions which can be included in a block, a fee transaction, a nofee transaction, and a no ID transaction. Fee transactions aretransactions which were mapped to a short ID by the BDN and include afee to the BDN system. No fee transactions are transactions which weremapped to a short ID by the BDN and do not include such a fee. No IDtransactions are transactions which were not mapped to a short ID by theBDN.

In an illustrative embodiment, the BDN system fees are implemented bypeer network nodes and not by the BDN because the BDN propagates blockswithout knowledge of their content. Whenever a peer receives (anddecrypts) a newly-mined block, it validates that at least 80% of theblock's size is used for fee transactions. Otherwise, the peer rejectsthe block. In alternative embodiments, a different percentage may beused, such as 70%, 90%, etc. Additionally, the use of an additionalpayee increases the size of transactions, but not the block size, sincetransactions are represented using short IDs regardless of their size.Thus, this process only increases the bandwidth used for transactiondissemination, which grows linearly with the size of the network and thesystem throughput, as opposed to exponentially.

The present BDN also employs several discrimination preventionmechanisms to ensure that the BDN propagates all blocks fairly, and isincapable of discriminating against any node, miner, block, transaction,or wallet. Block discrimination can be based on content of the blocksuch as wallets, addresses, sums of the transactions in a block,timestamps, coinbase transactions, or any other attributes. To preventdiscrimination based on block content, all blocks are encrypted prior topropagation. The BDN encryption alters the block size, which hides thenumber of transactions in the block and their total size. A block'sencryption key (k₁) is only revealed after the block had beenpropagated, and is propagated directly over the peer network. Theminuscule size of k₁, which can be as small as several bytes, allows itto quickly propagate directly over the peer network, and the BDN ispowerless to stop it.

Another anti-discrimination mechanism used by the BDN is indirect relayupon initial propagation of a block. To help ensure that the BDN is notpreventing individual nodes from propagating their blocks, whether basedon a node IP address, node operator identity, node implementation, orany other attribute, nodes do not propagate blocks directly to the BDNservers. Instead, a node wishing to propagate a block will firstpropagate it to a peer on the peer network, which will relay it to a BDNserver, thereby obscuring the origin of the block from the BDN.

In addition to indirectly relaying blocks to the BDN, nodes may requestthat their peers relay incoming blocks to them that arrive from the BDN.This ensures that the BDN cannot be used to discriminate against nodesthrough late delivery of blocks, and that nodes are not required todirectly interact with the BDN in order to benefit from its service. Theshort delay (i.e., ˜0.5 RTT) that such nodes experience for utilizingsuch a relay overlaps with the time required for nodes to receive k₁,nulling any negative effect.

While the BDN is oblivious to the node that originates each block, itmay potentially still block or stall blocks arriving from some subset ofnodes, affecting all of the blocks that are relayed by the subset. Inorder to detect and measure such behavior, nodes in the peer network areable to continuously test the BDN's service, and to communicate theresults to their peers. Such testing is achieved by allowing nodes tosend encrypted invalid blocks, referred to as test blocks, through theBDN. The sending nodes are then able to measure the time that it takesfor the recipient peers to report the arrival of the test blocks.Because of the encryption, the BDN servers are unable to distinguishbetween test blocks and valid blocks. The BDN servers are thereforeunable to employ a discriminating policy only over valid blocks, whilefaithfully propagating test blocks. From the perspective of the BDNservers, test blocks and valid blocks are indistinguishable until theirkeys are published. When a test block is distributed, any recipient peernodes then communicate the measurement results to their peers.

As noted above, the BDN system can also utilize a sentinel network. Thesentinel network is a global distributed network of servers, which isready to assume the role of the system servers in the event that thesystem servers fail to faithfully serve the peer network nodes, eitherdeliberately or as a result of a large-scale system failure. Thesentinel network runs the same open-source code as the system servers,and is generally meant to run over private virtual clouds (PVCs), e.g.,AWS, Microsoft Azure, Digital Ocean, Rackspace, etc. which can providehigh-bandwidth and low-latency communication.

The sentinel network differs from the BDN servers in two criticalaspects. First, while the BDN servers are centrally-managed, thesentinel network is a distributed network that allows anyone to join it.The operators of sentinel network servers run them in addition to andseparately from their peer network nodes. This allows the sentinelnetwork servers to act based on any discrimination their peer networksnodes observe. Second, whereas the BDN servers distribute large volumesof traffic, and thus incur high operational costs, the sentinel networkservers will only propagate traffic if the system servers fail tofaithfully distribute traffic, and their operational costs are thereforeminimal. The primary role of the sentinel network is thus not to be usedto propagate traffic. Rather, the primary role is to provide analternative to the system servers, allowing the peer network nodes notonly to monitor the BDN, but also to abandon the system servers shouldthe need arise. The existence of such an alternative is enough to deemfutile any colluding attempt by the system servers and/or peer networknodes. The sentinel network is thus passive, despite being an importantcomponent to ensure neutrality of the BDN system.

As discussed above, a key attribute of the BDN system is the ability ofpeer network nodes to audit the behavior of the BDN and to abandon it ifthe need arises. To that end, nodes relay test blocks to the BDN, andare able to determine whether their peers quickly receive them. However,the BDN and/or colluders could potentially attempt to relay a block froma given node only to its immediate peers, and not to the entire peernetwork. Such action could cause the originating node to falsely believeits blocks are relayed to the entire network. To prevent such abehavior, peer network nodes do not reveal all of the nodes that theyare aware of. Instead, nodes conceal half of the nodes that they areaware of, including half of their immediate peers. Thus, if an adversarywere to analyze the known peers of a node, it will be unable todetermine which nodes are its immediate peers and which are not. Inalternative embodiments, nodes may conceal a different percentage of thenodes they are aware of and/or their immediate peers, such as 40%, 45%,55%, 60%, etc.

Included below is an analysis of the different forms of discriminationthat a centralized BDN might attempt to employ, along with a discussionof how the above-discussed anti-discrimination mechanisms prevent theBDN from employing them. As discussed above, one form of discriminationis to stall or prevent the propagation of blocks based on block contentsuch as wallets, addresses, sums of the transactions in the block,timestamps, the coinbase transactions in the block, or any otherattribute. To prevent the BDN from such discrimination, blocks areencrypted prior to propagation. Furthermore, the encryption alters theblock size to hide the number of transactions in the block and theirtotal size. Each block's unique encryption key k₁, which is needed todecrypt the block, is only revealed after the block had been propagated.Also, the minuscule size of the key k₁ allows it to quickly propagatedirectly over the peer network, and the BDN is powerless to stop itspropagation.

Another form of discrimination is to prevent individual nodes frompropagating their blocks. Such discrimination can be based on IP addressof the node, the identity of the operator of the node, nodeimplementation, or any other node attribute. To ensure that the BDNcannot discriminate in this fashion, peer network nodes relay theirblocks indirectly. Rather than transmitting a block directly to a systemserver, an originating node propagates a block to a system serverthrough one or more of its peers, thereby preventing the recipientsystem server from knowing the origin of the blocks it receives.

Another form of discrimination is to stall or drop blocks arriving froma large subset of nodes, affecting all the blocks that are relayed bythe subset. However, if it is assumed that un-discriminated nodes arenot actively colluding with the BDN, relaying blocks though suchun-discriminated nodes negates the discrimination. Peer network nodesare able to periodically propagate test blocks through the BDN to ensurethat their blocks are indeed being propagated to the entire network inan unhindered fashion. Prevention and negation of collusion arediscussed in more detail below.

While transaction dissemination in the proposed BDN enables highersystem throughput, it is possible that the BDN can attempt to rejecttransactions and/or to demand unauthorized payment for the BDN service.To prevent the BDN from these forms of discrimination, approximately 20%of the size of each block is allowed to be dedicated to unmappedtransactions, i.e., transactions which have not been mapped to an ID. Inalternative embodiments, the percentage of block size that can bededicated to unmapped transactions can be less than or greater than 20%,such as 5%, 10%, 15%, 25%, 30%, etc. Allowing unmapped transactions tobe included in the block, combined with the encryption of blocks beforethey are relayed to the system servers, allows miners to include anytransaction in the blockchain. Importantly, this requirement is enforcedby the peer network nodes, and not by the system servers. As such, nodeswill reject blocks which do not follow the requirement. This mechanismensures that the majority of transactions are indeed mapped to IDs bythe BDN, thus allowing orders of magnitude higher throughput. At thesame time, this process prevents the system servers from rejectingspecific transactions, or blocks which contain specific transactions.

There are several forms of block delivery discrimination which acentralized BDN network might employ. First, the BDN can discriminate infavor of some nodes, delivering them blocks ahead of other nodes.Second, the BDN can discriminate against individual nodes by postponingblock delivery, or not delivering them blocks at all. Third, the BDN cancease to deliver blocks to a majority of nodes, and only serve a smallsubset of nodes. Lastly, the BDN can cease to deliver blocks completely,either maliciously or as a result of system failure.

To prevent the BDN from discriminating in favor of individual nodes, ablock's encryption key k₁ is only propagated after the node whichoriginated it (p_(source)) learns of the block's propagation from itspeers. Thus, any node (p_(privileged)) to receive the block ahead oftime will be forced to wait until it receives k₁ from its peers, whichwill only commence once the block is delivered to the arbitrary peers ofp_(source), thus placing p_(privileged) on a par with its peers.

To protect themselves from late block delivery, nodes compare betweentheir own test block arrival time and those of their peers, which willindicate whether or not they are being discriminated against. If a nodeidentifies such discrimination, nodes can request that their peers relayblock traffic directly to them, as soon as the traffic arrives. Thiswill place the discriminated nodes on par with their peers, as the shortdelay they suffer (˜0.5 RTT) overlaps with the time required for k₁ topropagate.

If the BDN ceases to deliver blocks completely, or only delivers blocksto a small subset of nodes, whether deliberately or as a result of alarge-scale failure, the sentinel network will assume the role of thesystem servers, and the nodes will abandon the system servers until thematter is resolved.

As discussed above, it is critical to prevent the BDN from censoring ordelaying blocks based on their content or origin. It is also critical toprevent discrimination in favor of or against any nodes utilizing it,even if the BDN colludes with nodes of the peer network. It is notedthat the design of the present BDN does not aim to solve the problem ofcolluding such as a 51% attack, nor to minimize its effectiveness.Rather, the design goal of the BDN is to not increase the effectivenessof existing attacks, and to not enable new attacks.

As outlined above, encrypted blocks are indirectly transmitted to thesystem servers, to prevent the system from discriminating againstblocks, whether based on their content or the nodes which originatedthem. However, colluding nodes might not relay blocks to the systemservers. Further, such colluding nodes might share their knowledge ofarriving blocks to allow the system servers to reject such blocksafterwards, when the blocks are relayed by non-colluding nodes. Suchattacks are bound to fail, however, as they require the system serversto reject all incoming test blocks, which in turn immediately alerts allnodes to the discrimination, and causes them to abandon the BDN in favorof the sentinel network.

As an example, p_(source) can relay b, b′¹, and k₁ to p₁, in a scenarioin which p₁ is actively colluding with the system servers. To prevent ordelay the propagation of b, colluders will refrain from propagating b′¹to the entire peer network, and possibly share all knowledge ofp_(source), b, k₁, and b′¹ among themselves. Once p_(source) relays theblock to p₁, it starts relaying b, b′¹, and k₁ to additional peers{p_(i)|i>1}, until it learns of a block that was successfully relayed.For the attack to succeed, the BDN must avoid or delay the propagationof blocks {b′¹|i>1} as they arrive from their respective nodes. Failingto do so, the attack will only delay the propagation of b by the timerequired for p_(source) to relay the block to its first non-colludingpeer, which is identical to the same attack vector in the p2p trustlessmodel.

Since p_(source) selects its peers at its own discretion, each peerp_(i) relays a version of b which is encrypted with a different key, andthe encryption obscures both the content and size of b, it is impossiblefor the BDN to distinguish between incoming test blocks and encryptedversions of b. Thus, to affect the propagation of b, the BDN must refuseall incoming blocks arriving from non-colluding nodes, possibly until adifferent block is provided by the colluding nodes. Such behavior isimmediately visible to all the nodes of the peer network, as they willfail to get reports of arrival for their own test blocks. In such ascenario, nodes immediately move to the sentinel network, which causesthe attack to fail, and furthermore causes the nodes to abandon thecolluding system servers in the short term. The system servers can bereplaced in the long term.

It is noted that a necessary condition for the attack to be launched isfor p₁, which is the first peer to which p_(source) relays the block, tobe colluding with the system servers. It is further noted thatdeliberate failure to relay blocks is already an existing attack vectorin the existing p2p trustless model, with the same probability ofsuccess. The result in both models, which is delaying the propagation ofa b until it is sent to p_(i), the first non-colluding node, isidentical. While blockchain systems utilizing the BDN are likely to useblocks which contain more transactions, the number of bytes utilized tosend a block to a peer network node is greatly reduced, due to the usageof short IDs to represent transactions. These effects negate each other,resulting in the attack having a similar level of effectiveness.

It is further noted that while it is also possible for the BDN to rejectonly a portion of blocks arriving from non-colluders, rather than all ofthem, such an attack is even less effective. For example, rejecting 50%of blocks arriving from non-colluders will only delay the propagation ofb by half the time (on average) required to relay a block through apeer, while being clearly visible to at least 50% of the nodes.Increasing the percentage of rejected nodes increases the visibilityeven further, while decreasing the visibility reduces its effect.

Lastly, it is worth noting that honest nodes of the peer network candetermine whether or not their test blocks are being relayed. If thetest blocks of a node are being relayed in the absence of ongoing nodediscrimination, nodes can directly relay their blocks to the systemservers, and obscure the validity of the block even from its peers.

In addition to colluding to prevent block propagation, nodes mightattempt to collude with the system servers to prevent or delay blockdelivery to a subset of the peer network nodes. When such an attack islaunched against a small number of nodes, it is easily discovered by thetargeted nodes, since their honest immediate peers, which are unknown tothe colluders, will notify them of the blocks and encryption keys theyreceive. To protect themselves, discriminated nodes can request any oftheir immediate peers to relay to them all incoming blocks. Such arequest does not place the discriminated node at the mercy of theselected peer(s), as the discriminated node continues to receive blocksfrom its other peers and from the system servers. Such a request alsodoes not place a heavy burden on the peer(s), as they control the numberof nodes to which they relay traffic. The presence of colluding nodesdoes not affect the effectiveness of the attack, which is identical tosuch an attack in a system using the p2p trustless model.

If such an attack is launched against a significant portion or themajority of non-colluding nodes, the dependence on peers to relay blocksbecomes a hindrance. This is because nodes are not as efficient inpropagating blocks as the system servers, giving colluders an advantageover non-colluding nodes. However, as the portion of discriminated nodesincreases, a proportional portion of sentinel server operators becomeaware of the discrimination, causing them to activate the sentinelnetwork, counter the attack, and abandon the system servers. In additionto discriminating against some of the nodes and/or blocks outlinedabove, it is possible for the BDN to completely terminate its service,either maliciously or as a result of system failure.

Unlike previously suggested scaling mechanisms, the deployment of theproposed BDN can be gradual, without requiring consensus or cooperationamong nodes. It is possible for a portion of the nodes to use the BDNwithout any change to the protocol, and the decision of how to adjustthe protocol in order to scale is then left to the miners and nodes ofeach cryptocurrency and blockchain. In this way, the miners and nodesare able to best utilize the benefits of the BDN in whichever way theysee fit. Every node of every cryptocurrency or blockchain can work ontop of the BDN, without being required to coordinate with any othernode.

The relaying of encrypted blocks opens the door for malicious behaviorand distributed denial of service (DDoS) attacks against the BDN andnodes, while communication among peers remains voluntary and at thediscretion of each node. To prevent malicious behavior such as thesending of large volumes of traffic via the BDN to the entire peernetwork, the BDN employs a simple yet effective policy of bandwidthlimitation. It is noted that the BDN should limit malicious behavior onthe one hand, while still allowing nodes to continuously monitor the BDNusing test blocks.

Given an average inter-block time interval t_(B), and an average size ofencrypted blocks which use IDs to represent their transactions B′, theBDN limits the traffic arriving from each node to 3B′ over a slidingwindow of 1500t_(B).

As an example, one can consider the scenario of Bitcoin aiming toachieve a throughput of 3,000 TPS using a block size of B=50 MB and aninter-block time interval of t_(B)=30 seconds among 50,000 nodes. If theBDN were to support it, and to reduce the transmitted block size toB′=0.5 MB, each node would be able to test its service over 5 times aday, while utilizing a download bandwidth of only 13 Mbps. As the peernetwork grows in size, the BDN can allow bandwidth-restricted nodes toreceive only a subset of the blocks, or to have their peers relay blocksto them only after they the blocks are determined to be valid.

In summary, the proposed BDN is the first network of its type to includethe described approaches to resolving the blockchain scaling problem.The proposed BDN introduces a centrally-managed network infrastructureto boost scalability, yet retains the decentralization of control overtransactions in a blockchain. This decentralization is implemented vianeutral and auditable network design. The proposed BDN is simultaneouslyscalable, neutral, and auditable. The scalability of the BDN increasessystem throughput by ˜1000×, via efficient content dissemination and byproviding a mapping service between transactions and short IDs to reducethe traffic volume. The BDN attains neutrality by supporting encryptedblocks and by obscuring the origin of blocks via peer relaying.Additionally, the BDN attains auditability by enabling clients todirectly and actively probe the network in a systematic manner. The BDNis a protocol-agnostic and economically viable system capable ofsupporting multiple blockchains simultaneously, and fully unleashingtheir indisputable potential.

In an illustrative embodiment, any of the operations described hereinmay be performed by a computing system that includes a memory,processor, user interface, transceiver, and any other computingcomponents. The operations can be stored as computer-readableinstructions on a computer-readable medium such as the computer memory.Upon execution by the processor, the computer-readable instructions areexecuted as described herein.

The word “illustrative” is used herein to mean serving as an example,instance, or illustration. Any aspect or design described herein as“illustrative” is not necessarily to be construed as preferred oradvantageous over other aspects or designs. Further, for the purposes ofthis disclosure and unless otherwise specified, “a” or “an” means “oneor more”.

The foregoing description of illustrative embodiments of the inventionhas been presented for purposes of illustration and of description. Itis not intended to be exhaustive or to limit the invention to theprecise form disclosed, and modifications and variations are possible inlight of the above teachings or may be acquired from practice of theinvention. The embodiments were chosen and described in order to explainthe principles of the invention and as practical applications of theinvention to enable one skilled in the art to utilize the invention invarious embodiments and with various modifications as suited to theparticular use contemplated. It is intended that the scope of theinvention be defined by the claims appended hereto and theirequivalents.

What is claimed is:
 1. A server in a blockchain distribution network,the server comprising: a transceiver configured to receive a transactionfrom a peer node; and a processor operatively coupled to thetransceiver, wherein the processor is configured to assign a transactionidentifier to the transaction; wherein the transceiver is configured topropagate the transaction identifier to one or more additional peernodes and one or more additional servers in the blockchain distributionnetwork; wherein the transceiver is configured to receive bytes of ablockchain that represents a plurality of transactions, wherein theblockchain includes the transaction identifier corresponding to thetransaction; and wherein the transceiver is configured to propagate thebytes of the blockchain to the one or more additional peer nodes and tothe one or more additional servers in the blockchain distributionnetwork.
 2. The server of claim 1, wherein a size of the transactionidentifier is two orders of magnitude less than a size of thetransaction.
 3. The server of claim 1, wherein the blockchain includes aplurality of transaction identifiers corresponding to the plurality oftransactions.
 4. The server of claim 1, wherein the bytes of theblockchain include a blockchain header.
 5. The server of claim 4,wherein the blockchain header includes a hash field, a time field, and anonce field.
 6. The server of claim 1, wherein the server furthercomprises a memory operatively coupled to the processor, wherein thememory is configured to store the transaction and the transactionidentifier.
 7. The server of claim 6, wherein the transceiver isconfigured to transmit the transaction along with the transactionidentifier to the one or more additional peer nodes and to the one ormore additional servers in the blockchain distribution network.
 8. Theserver of claim 7, wherein the transceiver is configured to transmit atime field along with the transaction and the transaction identifier,wherein the time field comprises a duration for which the transactionidentifier maps to the transaction.
 9. The server of claim 1, wherein asize of the transaction identifier is less than 5 bytes.
 10. The serverof claim 1, wherein the plurality of transactions of the blockchainincludes one or more transactions that do not have an associatedtransaction identifier.
 11. The server of claim 1, wherein thetransaction identifier in the blockchain is the only information in theblockchain corresponding to the transaction.
 12. The server of claim 1,wherein the processor is configured to determine transaction details ofthe transaction based on the transaction identifier included in theblockchain.
 13. The server of claim 12, wherein the transaction detailsinclude an amount of the transaction and a wallet associated with thetransaction.
 14. A method of propagating data in a blockchaindistribution network, the method comprising: receiving, by a transceiverof a server in the blockchain distribution network, a transaction from apeer node; assigning, by a processor operatively coupled to thetransceiver, a transaction identifier to the transaction; propagating,by the transceiver, the transaction identifier to one or more additionalpeer nodes and one or more additional servers in the blockchaindistribution network; receiving, by the transceiver, bytes of ablockchain that represents a plurality of transactions, wherein theblockchain includes the transaction identifier corresponding to thetransaction; and propagating, by the transceiver, the bytes of theblockchain to the one or more additional peer nodes and to the one ormore additional servers in the blockchain distribution network.
 15. Themethod of claim 14, further comprising propagating, by the transceiver,the transaction along with the transaction identifier to the one or moreadditional peer nodes and to the one or more additional servers in theblockchain distribution network.
 16. The method of claim 14, wherein asize of the transaction identifier is two orders of magnitude less thana size of the transaction.
 17. The method of claim 14, wherein theblockchain includes a plurality of transaction identifiers correspondingto the plurality of transactions.
 18. The method of claim 14, furthercomprising transmitting transmit a time field along with the transactionidentifier, wherein the time field comprises a duration for which thetransaction identifier maps to the transaction.
 19. The method of claim14, further comprising processing, by the processor, a header of theblockchain, wherein the header includes a hash field, a time field, anda nonce field.
 20. The method of claim 14, further comprisingdetermining, by the processor, transaction details of the transactionbased on the transaction identifier included in the blockchain.